Poster on Exception Handling in ADOME Workflow Management System

ADOME (Advanced Object Modeling Euviromnat) is au active OODBMS extended with role facilities, built by integrating ITASCA (OODB) and CLIPS (inference engine) iJiLo971. It provides a good supporting environment for the dynamic features required for a WFMS, especially for online exception handling, which can be classified along the following three dimensions: 1. Exception Source: external or worktlow. 2. Exception Type: expected or unexpected. 3. Exception Handling Mode: trivial, automatic, ooperative, manual, failure. In ADOME-WFMS, exception handlers can be procedural (extra branches of existing activity decomposition for exception handling) or declarative (in the form of ECA rules that can be specified within the scope of different activity and sub-activity levels). Both of them can be added, deleted and modified during activity definition time before execution, or during exception occurrence at run-time (viz. workflow evolution supported by the dynamic schema evolution capability of ADOME). In ADOME-WFMS, mechanisms for reuse of exception handlers follows from its structure [CKL971: l Arcs from more than one task / sub-activity can lead to the same exception handler.7 l only one declarative exception handler required for each exception type for a single activity composition hierarchy. l Declarative exception handlers (Iirst-class ECA rule objects) can be bound with more than one scope. l Exception classes are event objects arranged into an ‘isa’ hierarchy. l Exception handlers can be generalized by extending the event-part with ‘or’ event composition. Iu ADOME-WFMS, the following types of resolution are supported during manual or automatic exception handling: . Changes in Data / Objects (e.g. adding agents, resources or modify their individual properties) l Changes in Execution (e.g. retry, skip, abort current task or choose an alternate branch) l Schema Evolution (e.g. change in capability token hierarchy, PSA isa hierarchy, task requirement) l Workflow Evolution (e.g. adding procedural / declarative exception handlers or drastic restructuring of activities) When an exception occurs, the search for a haudler is horn the current task to its parent, then progressively up to the global activity (unless it is stopped by an explicit declaration) so as to allow for special exception handlers to override default exception handlers if required. If an exception is not handIed (either due to the WFMS or expert’s decision) in a sub-activity, the activity fails and triggers exception to its parent activity. This process may propagate up the composition hierarchy until it is handled. Further details of the ADOME-WFMS Exception Manager can be summar ized by the following me&i-activity diagram [CKL97].